In medium to large software projects, visual modeling is often critical to successful development. Visual modeling tools allow programmers to construct a picture of the various components of a software application and allow the programmers to see how the various components interface and interact. Traditionally, these modeling tools only have been used during the “analysis” and “design” activities at the beginning of the development process. Conventional modeling tools operated under the premise that an analysis and design model would be created first, and then code would be generated (manually or automatically) from the model. In theory, any subsequent changes or enhancements should be accomplished by changing the model, and then generating new/revised code. In practice, this approach was unworkable because many of changes are made at the code level during all phases of the development process including the testing, debugging, and maintenance phases.
With conventional modeling tools, when the code diverges from the initial design a large amount of work is required to keep the model and the underlying code in agreement. In a few cases, however, modified code can be processed by the modeling tool in order to update the model. Although useful, this approach suffers from the fact that the model and the code are two separate elements that are processed to generate one from the other rather than being two views of the same information. In addition, because the model and the code are separate entities, models are often developed that are very difficult, if not impossible, to implement. Another deficiency is that semantic information is lost during the process.
Recently, visual programming has received a great amount of attention, mainly because of its promise to make programming easier, thus allowing not only computer experts but also novices to implement software to solve problems with the computer. The goal of visual programming is to aid the development of complex software applications and increase productivity by allowing the programmer to abstract the software to a visual level. The programmer could theoretically develop and manipulate a software module of interest graphically, thereby replacing the need to code complex programming statements with the ability to directly manipulate a graphical object or objects representing the software module.
Conventional visual programming environments, however, failed to meet this lofty goal and typically consist of browsers for manipulating text, an editor to create graphical user interfaces (GUI's) and a rudimentary application skeleton generator. Conventional visual programming environments do not truly allow for software visualization and do not provide a true visual programming environment. Furthermore, as the programmer transitions from the graphical design to the actual programming, they typically lose structural information and semantic information.
Therefore, there is a need in the art for a visual development environment that offers both a method for visualizing an application and graphically constructing an application. There is a need for an environment that is a two-way development process, i.e., changes made graphically are instantly made textually and vice versa.